Split out from #207 at the maintainer's request. This PR contains only the driver swap and the adapter changes that come with it; the macOS Tahoe fork-safety fix stays in #207.

Why

Two motivations:

1. macOS Tahoe (26.4+) regression. Tahoe widened the set of system libraries that abort if initialized after fork() (CoreFoundation, Security.framework, libsystem_trace's os_log, libsystem_info's getaddrinfo). psycopg2 bundles libssl and pulls Security.framework into the parent at import time, which makes a forked child more likely to hit the abort path. psycopg v3 delegates TLS to libpq instead and avoids that import-time fingerprint. This was one of the crash classes covered by issue Broken pipe/worker connection closed errors in TUI only, inconsistently #189.
2. Maintenance. psycopg2 is in maintenance mode upstream; psycopg v3 is the actively developed branch with first-class type-hint support, native asyncio, and the modern API.

What the diff touches

The install-strategy unit tests in tests/test_install_strategy.py and tests/test_installer_cancel.py still use the literal string "psycopg2-binary" because they're exercising detect_strategy with a sample package name, not the real driver.

Two CursorBasedAdapter changes for psycopg v3 semantics

Running tests/integration/test_transactions.py against a real Postgres container with the psycopg3 adapter surfaced two driver-behavior differences:

• execute_non_query autocommit handling. The base adapter called conn.commit() after every non-query. psycopg2 silently makes commit() a no-op when conn.autocommit is True; psycopg v3 actively COMMITs any open transaction. So executor.execute("BEGIN") was immediately ending the transaction it just started, and the subsequent INSERT then auto-committed and ROLLBACK had nothing to undo. Skipping conn.commit() when getattr(conn, "autocommit", False) preserves intent on both drivers and is safe for adapters that don't set autocommit (mysql, mssql, sqlite, oracle, firebird — getattr returns False and the commit still fires).
• execute_query multi-statement walk. psycopg v3 exposes each result set from a multi-statement string and positions the cursor on the first set. After cursor.execute("BEGIN; INSERT; SELECT"), psycopg v3 leaves the cursor pointed at the BEGIN (no description, no rows). psycopg2 only ever surfaced the last set. Walking cursor.nextset() until it returns falsy lands on the last set; the loop is a no-op on drivers that don't implement nextset() (some raise NotSupportedError, hence the try/except).

Three test bugs the driver swap surfaced

These also reproduce on Maxteabag/sqlit:main with psycopg2 — verified by running the upstream tree against the same docker fixture. Fixing them here keeps the integration suite green:

• test_multi_statement_as_single_query_works sent BEGIN; INSERT; SELECT through the executor and left an open transaction on the persistent connection. The test's own DROP TABLE (on a fresh connection) then blocked waiting for the lock. Added a reset_tui_executor() before the cleanup so the persistent connection rolls back and releases the lock.
• test_atomic_execute_rolls_back_on_error asserted that atomic_execute raises on a failing statement. Per its docstring and current implementation it actually reports the failure via MultiStatementResult(completed=False, error_index=…). Updated the assertions accordingly.
• test_atomic_execute_commits_on_success asserted a single QueryResult for a 3-statement query. atomic_execute is documented to return a MultiStatementResult carrying each StatementResult; the trailing SELECT lands as result.results[-1].result.

Tests

Run against postgres:16 from infra/docker/docker-compose.test.yml:

Tradeoffs to flag

• Runtime dependency bump from psycopg2-binary>=2.9.0 to psycopg[binary]>=3.2.0. The adapter surface that sqlit actually uses is API-compatible, but it's still a real change for anyone bundling sqlit.
• The autocommit branch in the base execute_non_query is the smallest change that gives both drivers consistent behavior. An alternative would be to stop setting conn.autocommit = True in the PG adapter altogether and let psycopg v3 manage transactions natively via conn.transaction() — that's a bigger surface change and would also need the RuleAggregation workers to opt in. Happy to take that path instead if you'd prefer it.